Digital signature method and apparatus

ABSTRACT

A digital signature method and apparatus is provided in which a first party with a first public/private key pair forms an ambiguous signature on subject data using at least the private key of the first key pair, a keystone initially only known to the first party, and the public key of at least one other public/private key-pair. This signature is ambiguous in that a signature-checking party can only verify that the signature is in the set comprising a signature created by the first party and a respective signature created by the possessor of the private key of the or each of the key pairs the public key of which was used in creating the signature. Revelation of the keystone renders the signature unambiguous. Such an ambiguous signature can be used to implement a fair exchange of signatures between any number of parties, with the exchanged signatures being ambiguous signatures until revelation of the initial signer&#39;s keystone.

FIELD OF THE INVENTION

The present invention relates to a digital signature method andapparatus and in particular, but not exclusively, to the fair exchangeof digital signatures.

BACKGROUND OF THE INVENTION

It is well known to use a digital signature to provide a non-repudiableindication of the originator of a document (or other data) covered bythe signature. Typically, the signature creation and verificationprocesses involve a public/private key pair of the signer, the privatekey being used in creating the signature and the corresponding publickey in the verification process.

An example digital signature is the Schnorr signature as described inthe paper: “Efficient signature generation by smart cards” C. Schnorr.,in Journal of Cryptology, 4(3):161-174, 1991. According to thissignature scheme, there are two large primes p and q selected such thatq|p−1, which are published with an element g of (Z/pZ)* of order q. Asigner with private key x and public key g^(x) mod p signs a message Masfollows:

-   -   The signer chooses a random number t ε Z*_(q);    -   The signer computes:        h=Hash(g ^(t) mod p ∥M)        s=t−xh mod q        -   where ∥ represents concatenation    -   The signer outputs (s, h) as its signature on message M

Verification that the signature is from the sender and is on message Mis effected by a verifier (who knows the signer's public key g^(x) modp) by seeking to generate a value h′ that should match the value of h inthe signature. The verifier does this as follows:

-   -   The verifier first computes:        (g ^(t))′=g ^(s)(g ^(x))^(h) mod p        -   where s and h are the received signature values (it being            appreciated that if the values are correct, the right-hand            expression is equivalent to g^(t) mod p)    -   The verifies then computes:        h′=Hash ((g ^(t))′ mod p∥ M)        -   where M is the received message    -   The verifier then compares h′ and h which, if equal proves that        the message M was signed by the party having the public key        g^(x) mod p.

Electronic transactions frequently involve the exchange of signatures ondata representing commitments of the parties concerned. There is,however, an inherent problem of fairness in the sense that one partywill be the first to provide their signature and this can be abused bythe second party to the transaction. Thus, for example, the secondparty, being in possession of the first party's signature on somecommitment, can represent to an independent party that the transactionhas been completed by the second party having made a complimentarycommitment to the first party when, in reality, this has not been done.

The problem of fair commitment or fair exchange of signatures is afundamental problem in secure electronic transactions, especially wherethe parties involved are mutually distrustful. Up to now, there havebeen two different approaches to solving the problem of

exchanging signatures so that it is fair for both parties.

The first method involves the use of a (semi-trusted) arbitrator (Trent)who can be called upon to handle disputes between signers. The idea isthat Alice registers her public key with Trent in a one-timeregistration, and thereafter may perform many fair exchanges withvarious other entities. Trent may possibly learn some part of Alice'ssecret at this stage.

To take part in a fair exchange with Bob, Alice creates a partialsignature which she sends to Bob. Bob can be convinced that the partialsignature is valid (perhaps via a protocol interaction with Alice) andthat Trent can extract a full binding signature from the partialsignature. However, the partial signature on its own is not binding forAlice. Bob then fulfils his commitment by sending Alice his signature,and if valid, Alice releases the full version of her signature to Bob.The protocol is fair since if Bob does not sign, Alice's partialsignature is worthless to Bob, and if Bob does sign but Alice refuses torelease her full signature then Bob can obtain it from Trent. So thearbiter Trent may only be required in case of dispute (these arecommonly referred to as optimistic fair exchange protocols), but acertain amount of trust still has to be placed in Trent. However, themain problem that remains with such a scheme is that in general,appropriate arbitor are simply not available. Further details andreferences of such schemes can be found in the article “Breaking andRepairing Optimistic Fair Exchange from PODC 2003” Y. Dodis, and L.Reyzin, in ACM Workshop on Digital Rights Management (DRM), October2003.

The other common method of solving the problem of fair exchange ofsignatures is the idea of timed release or timed fair exchange ofsignatures in which the two parties sign their respective messages andexchange their signatures little by little. There are various problemswith this approach. The first is that the protocol is highly interactivewith many message flows. The second is that one party, say Bob, mayoften be at an advantage in that he sometimes has (at least) one morebit of Alice's signature than she has of his. This may not besignificant if the computing resources of the two parties are roughlyequivalent, but if Bob has superior computing resources, this may putBob at a significant advantage over Alice since Bob may terminate theprotocol early and use his resources to compute the remainder of Alice'ssignature, while it may be infeasible for Alice to do the same. Thereare methods to reduce this type of problem which involve the use ofspecial “timing” functions, but even if the fairness of the protocol isguaranteed by such methods, it is still too interactive for manyapplications. Further details and references for such schemes can befound in the paper “Timed Fair Exchange of Standard Signatures” J.Garay, and C. Pomerance in Proceedings Financial Crypto '03.

It may further be noted that the problem of avoiding one party'ssignature being abused by presentation to another party to prove somecommitment by the first party to a non-existent transaction, can beavoided by use of a signature that can only be verified by a designatedparty (such as the other party in a transaction). Such a signaturescheme (referred to as a Designated Verifier signature scheme) isdescribed in the paper “Designated verifier proofs and theirapplications” M. Jakobsson, K. Sako and R. Impagliazzo in Lecture Notesin Computer Science 1996, vol 1070. Signatures of this type areambiguous in that it is not possible for a party, who is not the signeror the designated verifier, to tell which of the signer or thedesignated verifier has created the signature. More particularly, in theimplementation described in the above-referenced paper, the signaturesare based on Schnorr signatures with the signer creating its signatureusing their own private key and the public key of the designatedverifier. The designated verifier can produce an alternate signature onthe same message using the verifier's own private key and the public keyof the signer. The nature of these signatures is such that theverification operation as operated by a signature-checking party who isnot the signer or designated verifier cannot tell whether a particularsignature is one produced by the signer or is, in fact, a correspondingalternate signature produced by the designated verifier. Thus, whilstthe designated verifier can prove that a signature created by the signerwas so created (because the designated verifier knows that he did not),the designated verifier cannot prove this to an independentsignature-checking party.

Another technique which was designed for different purpose but offersthe same ambiguity property is ring signatures. A ring signatureconvinces an external verifier that a message has been signed by one ofa number of possible independent signers without allowing the verifierto identify which signer it was. A 1-out-of-2 ring signature has all thesecurity features of the designated verifier signature with one signerand one designated verifier.

Further details and references of ring signature schemes can be found inthe articles “How to leak a secret” R. Rivest, A. Shamir and Y. Tauman,in Advances in Cryptology—Asiacrypt 2001, LNCS 2248, pages 552-565,Springer 2001; and “1-out-of-n signatures from a variety of keys” M.Abe, M. Ohkubo and K. Suzuki, in Cryptology—Asiacrypt 2002, LNCS 2501,pages 415-432, Springer 2002.

It is an object of the present invention to provide a signature schemefor transactions that is fair. It is a more general object of theinvention to provide a signature that is ambiguous until determinedotherwise by the signer.

SUMMARY OF THE INVENTION

According to the present invention, there is provided adigital-signature method for use, in signing subject data, by a firstparty that has a first public/private key-pair; the method comprisingthe first party generating a keystone and using it, together with atleast the private key of the first-party's key-pair, the public key ofat least one other public/private key-pair, and the subject data, tocreate, in a first way, an ambiguous signature which an independentsignature-checking party, without knowledge of the keystone, can onlyambiguously verify as being one of a set of ambiguous signaturescomprising: an ambiguous signature created in said first way by thefirst party, and a respective ambiguous signature created in a secondway by a possessor of the private key of the or each said otherkey-pair; knowledge of the keystone enabling the signature-checkingparty to determine that the ambiguous signature created by the firstparty was created thereby.

Advantageously, in the method of the foregoing paragraph, the firstparty uses the keystone to generate, by means of a one-way function, akeystone fix that the first party then uses in the creation, in saidfirst way, of its ambiguous signature on the subject data; the firstparty's ambiguous signature including a set of at least onekeystone-fix-related element and being such that:

-   -   the said second way of creating an ambiguous signature generates        an associated alternate keystone fix rather than using it as an        input; and    -   the signature-checking party requires a said set of at least one        keystone-fix-related element to ambiguously verify a said        ambiguous signature.

Upon the first party making the keystone available to thesignature-checking party, the signature-checking party can carry out averification process on a received data set that purports to come fromthe first party and comprises a said ambiguous signature and subjectdata; the verification process comprising the following operations inany order:

-   -   i) a determination of whether the or each element of said set of        at least one keystone-fix-related element included in the        ambiguous signature is derivable from the keystone, and    -   ii) an ambiguous verification operation for determining, on the        basis of the received data set and the public keys of the first        and said at least one other key-pairs, whether the ambiguous        signature in the data set is one of a set of ambiguous        signatures comprising: an ambiguous signature created in said        first way by the first party and a respective ambiguous        signature created in said second way by the possessor of the        private key of the or each said other key-pair;        positive determinations for both operations i) and ii)        indicating that the signature in the data set is an ambiguous        signature created in said first way and was therefore created by        the first party on the subject data.

Advantageously, the present invention can be applied to the exchange ofsignatures between two or more parties.

Thus, certain embodiments of the present invention provide aconcurrent-signaturemethod for simultaneously enabling signatureverification of digitally-signed data exchanged between first and secondparties that have associated respective public/private key-pairs, themethod comprising the steps of:

-   -   a) the first party:        -   generating a keystone and from this, a keystone fix;        -   generating an ambiguous signature using the keystone fix, at            least the private key of the first party's key-pair, the            public key of the second party's key-pair, and first subject            data;        -   making available, at least to the second party, a first data            set comprising the first subject data and the first-party's            ambiguous signature including said keystone fix;

b) the second party:

-   -   -   generating an ambiguous signature using the keystone fix            generated by the first party, at least the private key of            the second party's key-pair, the public key of the first            party's key-pair, and second subject data;        -   making available, at least to the first party, a second data            set comprising the second-party's ambiguous signature and            the second subject data;

    -   c) the first party revealing the keystone to remove the        ambiguity of the signatures so far as signature-checking parties        are concerned.

Until the keystone is released, both ambiguous signatures are deniable.However, once the keystone is released, the ambiguous signatures aresimultaneously transformed into binding signatures which bind the signedsubject datas to their true respective signers.

Other embodiments of the present invention provide a digital signaturemethod wherein each of n parties with respective public/privatekey-pairs, creates in turn an ambiguous signature based on:

-   -   at least the private key of its own key-pair,    -   the public keys of the other parties,    -   at least for the first n−1 signing parties, a keystone fix        derived from a keystone created by the party concerned, and    -   the keystone fixes of the preceding (i−1) signing parties, if        any;        the ambiguous signature of the i^(th) party requiring knowledge        of the keystones of the first i parties in said series to remove        its ambiguity whereby the first signing party can control,        subject to the prior release of the keystones of the other        parties, when all the ambiguous signatures become unambiguous        concurrently.

The present invention also encompasses apparatus for carrying out themethods of the invention, and computer program products for controllingcomputing apparatus to carry out the activities of one of the first,second and signature-checking parties according to the methods of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way ofnon-limiting example, with reference to the accompanying diagrammaticdrawings, in which:

FIG. 1 is a diagram illustrating the general operation of a concurrentsignature method embodying the invention;

FIG. 2 is a diagram illustrating the flow of protocol exchanges, andprocessing operations effected, in the course of a concurrent signatureprotocol embodying the invention;

FIG. 3 is a table showing values used by each of four parties whencomputing their respective ambiguous signatures in a concurrentsignature method based on ring signatures; and

FIG. 4 is a table similar to FIG. 3 but showing an alternative set ofvalues.

BEST MODE OF CARRYING OUT THE INVENTION

FIG. 1 illustrates the main steps of a concurrent signature method,embodying the invention, that involves two signing parties A and B (alsoconventionally called Alice and Bob). By “concurrent signature” is meantthat initially ambiguous signatures generated by A and B respectively onrespective messages M_(A), M_(B), can simultaneously be made unambiguousand binding, this being achieved by the release of a piece ofinformation herein referred to as a “keystone” initially only known tothe party who first signs its message (this being party A in FIG. 1).

Considering FIG. 1 in more detail, the party A has a public/private keypair X_(A)/x_(A) and party B has a public/private key pair X_(B)/x_(B).Party A wishes to conduct a transaction involving sending a messageM_(A) to party B and receiving back a message M_(B) from party B;however, party A does not wish the transaction to be binding until ithas received the desired reply M_(B) from party B. Party A thereforeproceeds as follows.

First, party A generates a keystone k which it initially keeps secretand uses to derive, via a one-way function, a “keystone fix” element f(see task circle 1 of FIG. 1). Party A then uses the keystone fix ftogether with A's private key x_(A) (and possibly A's public key), B'spublic key X_(B), and A's message M_(A), to create an ambiguoussignature σ_(A) (see box “ASIGN” in task circle 2). A now outputs thedata set <σ_(A), M_(A)> along with the keystone fix f—in fact, in thepresent specification, the convention is adopted that the keystone fix factually forms a discrete component of the ambiguous signature σ. Anambiguous signature will therefore comprise multiple components; it isto be understood that these components, and in particular the keystonefix f can be separately output from one another.

The signature σ_(A) is ambiguous in that an independentsignature-checking party V, without knowledge of the keystone k, canonly ambiguously verify the signature (see operation AVERIFY in taskcircle 3) as being either of: an ambiguous signature σ_(A) created by A,and an alternate ambiguous signature σ_(alt,B) created by B using analternate signing process “AltSIGN” (see dashed task circle 4) thattakes as input B's private key x_(B) (and possibly B's public key), A'spublic key X_(A), and the message M_(A), and outputs the alternateambiguous signature σ_(alt,B) (including an alternate keystone fixcomponent, different in value to f). In other words, whilst theambiguous verify operation AVERIFY can determine whether a message hasbeen signed either by A using ASIGN or by B using AltSIGN, AVERIFYcannot distinguish between these two possibilities. The ambiguous verifyoperation AVERIFY takes as input both a data set comprising an ambiguoussignature and the subject message, and the public keys X_(A), X_(B) ofthe parties concerned.

It is to be noted that whilst the ambiguous signatures produced by theASIGN and AltSIGN signing processes are indistinguishable so far asAVERIFY is concerned, the signing processes ASIGN and AltSIGN differsignificantly; in particular, as already indicated, the ASIGN processrequires the keystone fix as an input whereas, in contrast, the AltSIGNprocess generates the alternate keystone fix (that is, the alternatekeystone fix is not an input to AltSIGN).

With regard to the AltSIGN task circle 4 in FIG. 1, this is shown dashedas it indicates the potential to create the ambiguous signatureσ_(alt,B) rather than the actual creation of such a signature. It willalso be understood that the AVERIFY operation (task circle 3) need notactually be effected.

After B receives the data set <σ_(A), M_(A)>, B responds with messageM_(B) which it digitally signs using ASIGN (see task circle 5) toproduce an ambiguous signature σ_(B); the inputs to this ASIGN processare the keystone fix f generated by A, B's private key x_(B) (andpossibly B's public key), A's public key X_(A), and the message M_(B).The signature σ_(B) is ambiguous in the same way the signature σ_(A) isambiguous—that is, an independent signature-checking party V, withoutknowledge of the keystone k, can only ambiguously verify the signatureσ_(B) (see operation AVERIFY in task circle 6) as being either of: anambiguous signature σ_(B) created by B, and an alternate ambiguoussignature σ_(alt,A) created by A using the alternate signing process“AltSIGN” (see dashed task circle 7) with inputs of A's private keyx_(A) (and possibly A's public key), B's public key X_(B), and themessage M_(B). Again, it is to be understood that the dashed task circle7 simply indicates the potential to create the ambiguous signatureσ_(alt,A) rather than the actual creation of such a signature, and thatthe AVERIFY operation of task circle 6 need not actually be effected.The parties A and B are now at the stage that they have exchangedambiguously signed messages M_(A) and M_(B). If A is satisfied with themessage M_(B), A can now remove the ambiguity of the signatures σ_(A)and σ_(B) by releasing the keystone k (see reference 8) thereby enablingthe independent verifier V to verify (see VERIFY in task circle 9) thatA has digitally signed M_(A) with σ_(A) and B has digitally signed M_(B)with σ_(B). The VERIFY process involves:

-   -   checking that the keystone fix f is derivable from the keystone        k by using the same one-way function as used by A in originally        generating f;    -   checking, using the checked keystone fix value f, that the data        set <σ_(A), M_(A)> satisfies AVERIFY in which case the signature        σ_(A) on M_(A) must have been produced by A (this is because it        is not feasible to have derived a keystone value that would have        produced the alternate keystone fix value so that only a        signature produced by ASIGN—that is, A's ambiguous        signature—will satisfy AVERIFY for the keystone fix being used);    -   checking, using the checked keystone fix value f, that the data        set <σ_(B), M_(B)> satisfies AVERIFY in which case the signature        σ_(B) on M_(B) must have been produced by A.

A more formal exposition of a concurrent signature method embodying theinvention will next be given. The method uses a number of definedalgorithms to carry out its processing operations and these algorithmswill first be described individually for n parties before being linkedin a description, given with reference to FIG. 2, of aconcurrent-signature protocol that can be used in the case where n=2. Itwill be appreciated that in a practical embodiment of the concurrentsignature method the algorithms will typically be implemented in programcode used to control the operation of various items of computingapparatus associated with the parties involved (of course, dedicatedhardware can alternatively be used to implement some or all of thecryptographic functions involved).

The concurrent-signature algorithms are specified below and apply toconcurrent signature methods involving any number of parties n(including both the two-party method of FIG. 2 and the four-partymethods described hereinafter with reference to FIGS. 3 and 4):

SETUP A probabilistic algorithm that on input of a security parameter l,outputs all the systems parameters and sets the public/private keys ofall users in the system.

KGEN A probabilistic algorithm that maintains a list of tuples <k_(i),f_(i)> which is called the K-List, where k_(i), and f_(i) are each a setof strings. On input k, the algorithm proceeds as follows:

-   -   If k=ε, where ε is the empty string, select a random k′ ε Z_(q),        and let k=k′;    -   If the input k is already on the K-List in the tuple <k_(i),        f_(i)>, then output f_(i);        -   Otherwise compute a keystone fix f for k, output f and add            <k, f> to the K-List.

KREVEAL An algorithm that on input of f, where f is a keystone fixproduced by KGEN, finds the corresponding tuple <k, f> on the K-List andoutputs the keystone k of this tuple. If f is not on the K-List, thenthe algorithm outputs “invalid”.

ASIGN A probabilistic algorithm that outputs an ambiguous signature σ onM in response to input of <F, x_(i), X₁ . . . X_(n), M>, where F is aset of at least one keystone-fix-related element, X₁ . . . X_(n) arepublic keys (each for an individual possible signer), x_(i) is theprivate key corresponding to the public key X_(i), and M is a message.The public key X_(i) of the signer is also referred to below as the“primary” public key, whereas the other public keys used in thesignature are referred to as the “alternate” public keys. (It may benoted that for many specific implementations, X_(i) will not be arequired as an input to ASIGN either because it is not used in creatingthe ambiguous signature, or because it can be derived from x_(i)). Theambiguous signature σ includes a set R of at least onekeystone-fix-related element (in certain cases this set will be the sameas the set F).

AVERIFY An algorithm that outputs “accept” or “reject” in response toinput of <σ, X₁ . . . X_(n), M> where σ is an ambiguous signature X₁ . .. X_(n) are public keys, and M is a message,

VERIFY An algorithm which takes as input <k_(j,j=1, 2, . . . , m,),S_(i, i=1, 2, . . . , n)> where k_(j) is a keystone and each S_(i) is ofform S_(i)=<σ_(i), X₁, X_(2 . . .) X_(n), M_(i)> where σ_(i) is anambiguous signature on M_(i) and includes a set R ofkeystone-fix-related elements. For each S_(i) the algorithm checks ifeach element of R in σ_(i) is derivable from the keystone fix valuesproduced by KGEN(k_(j, j=1 . . . m)); if this is not the case, thealgorithm terminates with output “reject”. Otherwise, the algorithm runsAVERIFY for the next S_(i) and outputs “accept” if all AVERIFYs outputsare “accept” and otherwise outputs “reject”.

FIG. 2 illustrates the use of the foregoing algorithms for a concurrentsignature protocol exchange between two parties A and B (or,conventionally, Alice and Bob). The party that creates the keystone andsends the first ambiguous signature is termed the initial signer and, inthis example,this is party A; the party who responds to the initialsignature by creating another ambiguous signature is termed the matchingsigner, this being party B in this example. The subscripts A and B areused to indicate the initial signer A and matching signer Brespectively. In FIG. 2, the flow of the protocol is depicted by thedashed arrows whilst solid arrows are used to indicate the inputs andoutputs of the various signature algorithms.

The operation of the concurrent signature protocol is as follows:

-   -   At step 10: A and B run SETUP to determine the parameters of the        scheme. In particular, on completion of SETUP, A has public and        private keys X_(A) and x_(A) respectively and B has public and        private keys X_(B) and x_(B) respectively. A and B each know the        other's public key. One of the parties (here A), proceeds first        and takes the role of initial signer.    -   At step 11: A picks a random keystone k, and computes a keystone        fix f=KGEN(k).    -   At step 12: A runs the ASIGN algorithm, using as inputs the        keystone fix f (for the set F), A's own private key x_(A), A's        public key X_(A) as the primary public key, B's public key X_(B)        as the alternate public key, and a message M_(A) chosen by A for        signature. The output of ASIGN is A's ambiguous signature on        M_(A):        σ_(A)=ASIGN(f, x _(A) , X _(A) , X _(B) , M _(A))    -   which A sends to B along with the message M_(A) (dashed arrow        13). The signature σ_(A) includes the keystone fix f as the sole        element of the set R. The elements σ_(A) and M can passed to B        in any suitable manner and may be passed independently of each        other.    -   At step 14: Upon receipt of A's ambiguous signature σ_(A), B        verifies the signature by checking that: AVERIFY(σ_(A), X_(A),        X_(B), M_(A))=“accept”. If not B aborts, otherwise B proceeds to        step 15.    -   At step 15: B runs the ASIGN algorithm using as inputs the        keystone fix f (for F), B's own private key x_(B), B's public        key X_(B) as the primary public key, A's public key X_(A) as the        alternate public key, and a message M_(B) chosen by B for        signature. B uses the same keystone fix f in his signature as A        did to produce σ_(A). The output of ASIGN is B's ambiguous        signature σ_(B) on message M_(B):        σ_(B)=ASIGN(f, x _(B) , X _(B) , X _(A) , M _(B))    -   which B sends to A along with message M_(B) (dashed arrow 16).        Again, the set R for this signature is formed by f.    -   At step 17: Upon receipt of B's ambiguous signature σ_(B), A        verifies the signature by checking that AVERIFY(σ_(B), X_(B),        X_(A), M_(B))=“accept”. If the output of AVERIFY is “reject” A        aborts, otherwise A proceeds to step 18.    -   At step 18: A publishes the keystone k=KREVEAL(f).    -   At step 20: Once the keystone k has been released by A, the        keystone fix f can be shown to be derived from keystone k and        <k,S_(A)> and <k,S_(B)> will both be accepted by VERIFY where:        S _(A)=<σ_(A) , X _(A) , X _(B) , M _(A)>        S _(B)=<σ_(B) , X _(B) , X _(A) , M _(B)>        First Specific Two-Party Implementation

A first specific implementation of the FIG. 2 concurrent signaturemethod will now be described, this implementation being based on adevelopment of the form of Schnorr signature used in the DesignatedVerifier scheme referred to in the introductory portion of the presentspecification.

The concurrent-signaturealgorithms(SETUP, KGEN, KREVEAL, ASIGN, AVERIFYand VERIFY) are as follows:

-   -   SETUP Two large primes p and q are selected such that q|p−1.        These are published with an element g of (Z/pZ)* of order q. Two        suitable hash functions H₁, H₂: {0,1}* are also selected (such        as any of the SHA Secure Hash Algorithms). Private keys chosen        randomly are of the form x_(i)ε Z_(q), and are kept secret. The        public keys are computed as:        X_(i)=g^(x) ^(i) mod p        and are made public.

KGEN A probabilistic algorithm that takes as input k ε Z_(q) where k isa keystone. The algorithm maintains a list of tuples <k_(i2),f_(i)>which is called the K-List. On input k, the algorithm proceeds asfollows:

-   -   if k=ε, where ε is the empty string, select a random k′ ε Z_(q),        and let k=k′;    -   If the input k is already on the K-List in the tuple        <k_(i),f_(i)>, then output f_(i);    -   Otherwise the algorithm outputs a keystone fix f=<u,v> where        u=H₁(k∥0), and v=H₁(k∥1), and adds <k,f> to the K-List.

KREVEAL An algorithm that on input f=<u,v> where f is a keystone fix. Ifthere exists a tuple <k,f> on the K-List, then the algorithm returns k,otherwise it outputs “invalid”.

ASIGN A signer takes as inputs <f, x₁, X₁, X₂, M>, where f=<u, v> is akeystone fix, x₁ is the private key of the signer, X₁ is the primarypublic key (the signer's public key), X₂ is the alternate public key,and M is a message, and proceeds as follows:

-   -   The signer picks a random value t ε Z_(q) and then computes the        values        w=g^(u)X₂ ^(v) mod p        h=H ₂(g ^(t) ∥ w∥ M)        s=t−x ₁(h+u) mod q    -   The signer outputs the ambiguous signature σ=<s, h, f>.

It may be noted that in the present example, ASIGN need not take X₁ asan input since this can be computed from g and x₁.

AVERIFY A verifier takes input <σ, X₁, X₂, M> where σ=<s, h, f> is anambiguous signature, X₁ and X₂ are the primary and alternate publickeys, and M is a message. The algorithm proceeds as follows:

-   -   The verifier computes:        (g ^(t))=g ^(s) X ₁ ^(h+u) mod p        -   which should correspond to g^(t) as t=s+x₁(h+u)            w′=g ^(u) X ₂ ^(v) mod p        -   which should correspond to w            h′=H ₂((g ^(t))′ ∥ w′ ∥ M)    -   The verifier then checks that the equation:        h′=h        holds, and if so, outputs “accept”; otherwise the verifier        outputs “reject”.

VERIFY An algorithm which takes as input <k, S_(i)> where k is akeystone and each S_(i)=<σ_(i), X_(i1), X_(i2), M_(i)> where σ_(i) is anambiguous signature on M_(i) and includes the keystone fix f, and X_(i1)and X_(i2) are primary and alternate public keys. If not all S_(i) havethe same keystone fix f, terminate and output “reject”, otherwise checkif KGEN(k)=f. If the check KGEN(k)=f fails, terminate and output“reject”, otherwise run AVERIFY for each S_(i). Output “accept” only ifall AVERIFYs output “accept”, otherwise output “reject”.

Referring to the concurrent signature protocol exchanges illustrated inFIG. 2, in the case of the present specific implementations of thesignature algorithms, the elements h_(A) and s_(A) of the ambiguoussignature σ_(A) output by ASIGN at step 12 take the form:h _(A) =H ₂(g ^(t) ^(A) ∥g ^(u)(X _(B))^(v) mod p ∥ M _(A))

-   -   where t_(A) is the random number t used by this instance of        ASIGN,        s _(A) =t _(A) −x _(A)(h _(A) +i) mod q        and the value of h′ computed during execution of AVERIFY in step        14 is:        h _(A) ′=H ₂(g ^(s) ^(A) (X _(A))^(h) ^(A) ^(+u) ∥ g ^(u)(X        _(B))^(v) mod p ∥ M _(A))

Similarly, the elements h_(B) and s_(B) of the ambiguous signature σ_(B)output by ASIGN at step 15 take the form:H _(B) =H ₂(g ^(t) ^(B) ∥ g ^(u)(X _(A))^(v) mod p ∥ M _(B))

-   -   where t_(B) is the random number t generated by this instance of        ASIGN,        s _(B) =t _(B) −x _(B)(h _(B) +u) mod q        and the value of h′ computed during execution of AVERIFY in step        14 is:        h _(B) ′=H ₂(g ^(s) _(B)/(X _(B))^(h) ^(B) ^(+u) ∥ g ^(u)(X        _(A))^(v) mod p ∥ M _(B))

As regards the ambiguity of the signatures σ_(A) and σ_(B), thefollowing algorithm AltSIGN illustrates how one party, here called thealternate signer, can generate a signature that is capable of satisfyingAVERIFY with the other party's public key as the primary public key X₁and the alternate signer's public key as the alternate public key X₂(and therefore indistinguishable, so far as AVERIFY is concerned, from asignature σ produced by the other party using ASIGN). The AltSIGNalgorithm takes as input <x₂, X₂, X₁, M>, the alternate signer being theparty associated with the public/private key pair X₂/x₂.

The alternate signer B picks random values α ε Z_(q), β ε Z_(q), s εZ_(q) and then computes the valuesw=g^(a) mod pg ^(t) =g ^(s)(X ₁)^(β) mod ph=H ₂(g ^(t) ∥w ∥ M)u=β−h mod qv=(α−u)/x ₂ mod q

The alternate ambiguous signature σalt is then =<s, h, f> where f is thealternate key fix comprising the values of u and v just computed inAltSIGN.

When AVERIFY is applied to σ_(alt), the message M and the primary andalternate public keys X₁, X₂, the verifier computes:(g ^(t))′=g ^(s) X ₁ ^(h+u) mod p

-   -   which should correspond to g^(t) as h+u=β        w′=g^(u)X₂ ^(v) mod p    -   which should correspond to w as X₂ ^(v)=(g^(x) ² )^((a−u)/x) ²        =g^((a−u)) mod p    -   h′=H ₂((g ^(t))′ ∥ w′ ∥M)

The verifier then checks that the equation h′=h is satisfied.

As already noted in general terms in discussing FIG. 1, the alternatekeystone fix values of u and v are computed during the course of AltSIGNand are not initial input values as is the case for ASIGN. As a result,it is not computationally feasible to determine the keystone k fromwhich the alternate keystone fix values u and v could have been derived(the hash function H₁ being a one-way function). Therefore revelation ofthe keystone k by the initial signer A is sufficient to remove ambiguityfrom the ambiguous signatures since it establishes the proper keystonefix values v and u—if AVERIFY is satisfied using these values, then theidentity of the signer of a signature being tested by AVERIFY is givenby the primary public key X₁ used in the AVERIFY algorithm.

Second Specific Two-Party Implementation

A second specific implementation of the FIG. 2 concurrent signaturemethod will now be described, this implementation being based on adevelopment of the form of Schnorr signature used in the ring signaturescheme referred to in the above-mentioned paper “1-out-of-n signaturesfrom a variety of keys” M. Abe, M. Ohkubo and K. Suzuki, inCryptology—Asiacrypt 2002, LNCS 2501, pages 415-432, Springer 2002.

The concurrent-signaturealgorithms(SETUP, KGEN, KREVEAL, ASIGN, AVERIFYand VERIFY) are as follows:

SETUP Two large primes p and q are selected such that q|p−1. These arepublished with an element g of (Z/pZ)* of order q. Two suitable hashfunctions H₁, H₂: {0,1}* are also selected (such as any of the SHASecure Hash Algorithms). Private keys chosen randomly are of the formx_(i) ε Z_(q), and are kept secret. The public keys are computed as:X_(i)=g^(x) ^(i) mod pand are made public.

KGEN A probabilistic algorithm that takes as input k ε Z_(q) where k isa keystone. The algorithm maintains a list of tuples <k_(i), f_(i)>which is called the K-List. On input k, the algorithm proceeds asfollows:

-   -   if k=ε, where ε is the empty string, select a random k′ ε Z_(q),        and let k=k′;    -   If the input k is already on the K-List in the tuple <k_(i),        f_(i)>, then output f_(i);    -   Otherwise the algorithm outputs a keystone fix f=H₁(k) adds <k,        f> to the K-List.

KREVEAL An algorithm that on input a keystone fix f. If there exists atuple <k, f> on the K-List, then the algorithm returns k, otherwise itoutputs “invalid”.

ASIGN A signer takes as inputs <f, x₁, X₂, M>, where f is a keystonefix, x₁ is the private key of the signer, X₁ is the primary public key(the signer's public key), X₂ is the alternate public key, and M is amessage, and proceeds as follows:

-   -   The signer picks a random value t ε Z_(q) and then computes the        values        h=H ₂(g ^(t) X ₂ ^(f) ∥ M)        w=h−f mod q        s=t−wx ₁ mod q    -   The signer outputs the ambiguous signature σ=<s, w, f>.

It may be noted that in the present example, ASIGN need not take X₁ asan input since this can be computed from g and x₁.

AVERIFY A verifier takes input <σ, X₁, X₂, M> where σ=<s, w, f> is anambiguous signature including keystone fix f X₁ and X₂ are the primaryand alternate public keys, and M is a message. The algorithm proceeds asfollows:

-   -   The verifier computes:        h=f+w mod q        h′=H ₂(g ^(s) X ₁ ^(w) X ₂ ^(f) mod p ∥ M)        -   It may be noted that the term (g^(s)X₁ ^(w)X₂ ^(f) mod p)            should be equal to the term (g^(t)X₂ ^(f) mod p) used in            computing h in ASIGN, since:            g ^(s) X ₁ ^(w) X ₂ ^(f) =g ^((t−wx) ¹ ⁾ g ^(x) ¹ ^(w) g            ^(x) ² ^(f) =g ^(t) g ^(x) ² ^(f) =g ^(t) X ₂ ^(f) mod p    -   The verifier checks whether:        h′=h        holds, and if so, outputs “accept”; otherwise outputs “reject”.

VERIFY An algorithm which takes as input <k, S_(i)> where k is akeystone and each S_(i)=<σ_(i), X_(i1),X_(i2),M_(i)> where σ_(i) is anambiguous signature on Mi and including keystone fix f and X_(i1) andX_(i2) are primary and alternate public keys. If not all S_(i) have thesame keystone fix f, terminate and output “reject”, otherwise check ifKGEN(k)=f. If the check KGEN(k)=f fails, terminate and output “reject”,otherwise run AVERIFY for each S_(i). Output “accept” only if allAVERIFYs output “accept”, otherwise output “reject”.

Referring to the concurrent signature protocol exchanges illustrated inFIG. 2, in the case of the present specific implementations of thesignature algorithms, the elements w_(A) and s_(A) of the ambiguoussignature σ_(A) output by ASIGN at step 12 take the form:h _(A) =H ₂(g ^(t) ^(A) X _(B) ^(f) ∥ M _(A))w _(A) =h _(A) −f mod qs _(A) =t _(A) −w _(A) x _(A) mod q

-   -   where t_(A) is the random number t used by this instance of        ASIGN, and f is the keystone fix computed by A in step 11;        and the value of h_(A)′ computed during execution of AVERIFY in        step 14 is:        h _(A) ′=H ₂(g ^(s) ^(A) X _(A) ^(w) ^(A) X _(B) ^(f) ∥ M _(A))        mod q.

Similarly, the elements w_(B) and s_(B) of the ambiguous signature σ_(B)output by ASIGN at step 15 take the form:h _(B) =H ₂(g ^(t) ^(B) X _(A) ^(f) ∥ M _(B))w _(B) =h _(B) −f mod qs_(B) =t _(B) −w _(B) x _(B) mod q

-   -   where t_(B) is the random number t used by this instance of        ASIGN, and the value of h_(B)′ computed during execution of        AVERIFY in step 14 is:        h _(B) ′=H ₂(g ^(s) ^(B) X _(B) ^(w) ^(B) X _(A) ^(f) ∥ M _(B))        mod q.

As regards the ambiguity of the signatures σ_(A) and σ_(B), thefollowing algorithm AltSIGN illustrates how one party, here called thealternate signer, can generate a signature that is capable of satisfyingAVERIFY with the other party's public key as the primary public key X₁and the alternate signer's public key as the alternate public key X₂(and therefore indistinguishable, so far as AVERIFY is concerned, from asignature σ produced by the other party using ASIGN ). The AltSIGNalgorithm takes as input <x₂, X₁, M>, the alternate signer being theparty associated with the public/private key pair X₂/x₂.

The alternate signer picks random values α ε Z_(q) and t ε Z_(q) andthen computes the valuesh=H ₂(g ^(t) X ₁ ^(α) ∥ M _(A))f=h−α mod qs=t−fx _(B) mod q

The alternate ambiguous signature σ_(alt) is then =<s, α, f>, which isindistinguishable from σ=<s, w, f> above from the external verifier'spoint of view.

Thus, when AVERIFY is applied to σ_(alt) the verifier then checks thatthe equationα+f=H ₂(g ^(s) X ₁ ^(α) X ₂ ^(f) ∥ M _(A)) mod qis satisfied.

Again, the alternate keystone fix value of f is computed during thecourse of AltSIGN and is not an initial input value as is the case forASIGN. As a result, it is not computationally feasible to determine thekeystone k from which the alternate keystone fix f could have beenderived (the hash function H₁ being a one-way function). Thereforerevelation of the keystone k by the initial signer A is sufficient toremove ambiguity from the ambiguous signatures since it establishes theproper keystone fix value f—if AVERIFY is satisfied using these values,then the identity of the signer of a signature being tested by AVERIFYis given by the primary public key X₁ used in the AVERIFY algorithm.

In the foregoing two-party concurrent signature examples, it would bepossible for one or other or both of A and B to create its ASIGNsignature using for the alternate public key the public key of a new,unbound, public/private key pair chosen by the signing party; thesigning party publishes both the public and private keys of this new keypair with the result that anyone could be responsible for generating analternate signature using AltSIGN. In effect, the potential alternatesigner is an anonymous signer. The ambiguity in the signature is onlyremoved when the signing party releases the keystone. Where both A and Bchoose to do this, they could each use a respective new public/privatekey pair or B could use the same new key pair as A. One drawback of Adoing this is that B cannot then be sure at step 14 in FIG. 2 that M_(A)has actually been signed by A; however, where B uses such a key pair, itis possible for A at step 17 to determine whether M_(B) has been signedby B because it knows what is the correct value of the keystone fix f(that is, the value derived from the keystone k).

It may be noted that the party A can also effectively carry out theforegoing concurrent signature methods with multiple other parties eachof which has its own respective public/private key-pair; in this case,each of these other parties acts like party B in the above-describedembodiments but now party A does not release the keystone untilsatisfied with the messages it receives back from every one of theseother parties. In this multiple other-party case, party A can create arespective digitally-signedmessage for each other party using eitherthat party's public key or an anonymous public key (with generally-knowncorresponding private key) as the alternate public key in ASIGN;alternatively, party A can use the same digitally-signed message for allother parties with an anonymous public key being used as the alternatepublic key in ASIGN. Furthermore, each other party when responding canuse either party A's public key or an anonymous public key (withgenerally-known corresponding private key) as the alternate public keyin ASIGN; each of the other parties will, of course, use the samekeystone fix as party A in creating its ambiguous signature.

The involvement of multiple parties with the initial signer in theforegoing manner is effectively a collection of two-party signatureswith the initial signer being clearly at the hub of activity and theother parties having no real relationship with each other. A concurrentsignature arrangement that places the parties in a more equal positioneven when there are three or more parties will next be described.

Concurrent Signatures with More Than Two Parties

The above two-party concurrent signature example based on ringsignatures can be extended to n parties to provide fairness for each ofthe parties involved. The algorithms ASIGN and AVERIFY given above forthe ring-signature example are readily extended to the n-party case byincluding additional terms corresponding to the public keys of theadditional parties as will become apparent from the following examplewith n=4. The four parties involved are identified below as parties A,B, C and D with respective public/private key pairs X_(A)/x_(A),X_(B)/x_(B), X_(C)/x_(C), and X_(D)/x_(D) provided by SETUP.

A Initiates the Protocol:

A uses KGEN to creates a keystone value k_(A) at random and compute(n−1) components of a keystone fix f_(A) where n is the number ofparties; in this example, n=4 so three components f_(A1), f_(A2) andf_(A3) are computed:f _(A1) =H(k _(A) ∥ 1) f _(A2) =H(k _(A) ∥ 2) f _(A2) =H(k _(A) ∥3)

-   -   It will be appreciated that the constants concatenated with        k_(A) can have any predetermined values provided they are        different from each other.

Using F_(A)=<f_(A1), f_(A2), f_(A3)>, A's private key, the public keysof the other parties, and M_(A) as inputs, A computes an ambiguous ringsignature as follows (this being the ASIGN process for this concurrentsignature method):

-   -   A chooses t_(A) ε Z_(q) at random    -   A computes        h _(A) =H ₂(g ^(t) ^(A) X _(B) ^(f) ^(A1) X _(C) ^(f) ^(A2) X        _(D) ^(f) ^(A3) mod p ∥ M _(A))        -   (note the additional terms X_(C) ^(f) ^(A2) X_(D) ^(f) ^(A3)            as compared to the two party case)            w _(A) =h _(A)−(f _(A1) +f _(A2) +f _(A3)) mod q        -   (the term (f_(A1)+f_(A2)+f_(A3)) corresponds to the sum of            the exponents of the public keys in the expression for            h_(A))            s_(A) =t _(A) −w _(A) x _(A) mod q

A releases the ring signature <s_(A), w_(A), f_(A1), f_(A2), f_(A3)>,the ordering of the last four quantities indicating their association,as exponents, with the public keys of the parties A, B, C and Drespectively (for example, in AVERIFY as will become clear hereinafter).The elements f_(A1), f_(A2), f_(A3) form the set R_(A).

B Follows A:

B uses KGEN to creates another keystone value k_(B) at random andcompute a single-component keystone fix f_(B1)=H(k_(B)∥ 1),

Using F_(B)=<f_(A1), f_(A2), f_(A3), f_(B1)>, B's private key, thepublic keys of the other parties, and M_(B) as inputs, B computes itsambiguous ring signature as follows (again, this is the ASIGN process):

-   -   B chooses t_(B) ε Z_(q) at random    -   B computes        h _(B) =H ₂(i g^(t) _(B) X _(A) ^((f) ^(A1) ^(⊕f) ^(A2) ⁾ X _(C)        ^(F) ^(A3) X _(C) ^(f) ^(B1) mod p ∥ M _(B))        w _(B) =h _(B)−((f _(A1) ⊕f _(A2))+f _(A3) +f _(B1)) mod q        s _(B) =t _(B) −w _(B) x _(B) mod q

B releases the ring signature <s_(B), (f_(A1)⊕F_(A2)), w_(B), f_(A3),f_(B1)>. Again, the ordering of the last four quantities indicates theirassociation, as exponents, with the public keys of the parties A, B, Cand D respectively. The elements (f_(A1)⊕f_(A2)), f_(A3), f_(B1) of thesignature form the set R_(B).

C Follows B:

C uses KGEN to create another keystone value k_(C) at random and computea single-component keystone fix f_(C1)=H(k_(C)∥1),

Using F_(C)=<(f_(A1)⊕f_(A2)), f_(A3), f_(B1), f_(C1)>, C's private key,the public keys of the other parties, and M_(C) as inputs, C computesits ambiguous ring signature as follows (again, this is the ASIGNprocess):

-   -   C chooses t_(C) ε Z_(q) at random    -   C computes        h _(C) =H ₂(g ^(t) _(C) X _(A) ^((f) ^(A3) ^(⊕f) ^(B1) ⁾ X _(D)        ^(f) ^(C1) mod p ∥ M _(C))        w _(C) =h _(C)−((f _(A1) ⊕f _(A2))+(f _(A3) ⊕f _(B1))+f _(C1))        mod q        s _(C) =t _(C) −w _(C) x _(C) mod q

C releases the ring signature <s_(C), (f_(A3)⊕f_(B1)), (f_(A1)⊕f_(A2)),w_(C), f_(C1)> Again, the ordering of the last four quantities indicatestheir association, as exponents, with the public keys of the parties A,B, C and D respectively. The elements (f_(A3)⊕f_(B1)), (f_(A1)⊕f_(A2)),f_(C1) of the signature form the set R_(C).

D Follows C:

D does not generate a keystone or keystone fix.

D uses F_(D)=<(f_(A3)⊕f_(B1)), (f_(A1)⊕f_(A2)), f_(C1)>, D's privatekey, the public keys of the other parties, and M_(D) as inputs, tocompute its ambiguous ring signature as follows (again, this is theASIGN process):

-   -   D chooses t_(D) ε Z_(q) at random    -   D computes        h _(D) =H ₂(g ^(t) ^(D) X _(A) ^(f) ^(C1) X _(B) ^((f) ^(A3)        ^(⊕f) ^(B1) ⁾ X _(C) ^((f) ^(A1) ^(⊕f) ^(A2) ⁾ mod p ∥ M _(D))        w _(D) =h _(D)−(f _(C1)+(f _(A1) ⊕f _(A2))+(f _(A3) ⊕f _(B1)))        mod q        s _(D) =t _(D) −w _(D) x _(D) mod q

D releases the ring signature <S_(D), f_(C1), (f_(A3)⊕f_(B1)),(f_(A1)⊕f_(A2)), w_(D)> Again, the ordering of the last four quantitiesindicates their association, as exponents, with the public keys of theparties A, B, C and D respectively. The elements f_(C1),(f_(A3)⊕f_(B1)), (f_(A1)⊕f_(A2)) of the signature form the set R_(D).

Keystone Release

After having the four ring signatures, C uses KREVEAL to release k_(C).

After having the four ring signatures and k_(C), B uses KREVEAL torelease k_(B).

After having the four ring signatures and both k_(C) and k_(B), A usesKREVEAL to releases k_(A).

With all keystones k_(A), k_(B) and k_(C)released, the four ringsignatures become unambiguous. In fact, it is keystone k_(A) that is thetrue keystone since, provided the other keystones have been releasedfirst, its release renders all the signatures unambiguoussimultaneously.

It will be understood that some way needs to be provided ofdistinguishing, in each signature, between the element w and theelements of the set R of keystone-fix-related components so that asubsequent signer uses the correct parts of a preceding signature whenderiving its own signature. This can be achieved in a variety of ways,including, for example, by explicit indications embedded in thesignature, or by ordering the parts of the signature as indicated andthen using a knowledge of the order of generation of the signatures toidentify the parts of the signature.

The AVERIFY algorithm on receiving any of the ambiguous signatures andthe related message M, assumes the first value in the signature to bethe quantity s and the remaining values to be exponents y_(A), y_(B),y_(C), y_(D) to be applied to the public keys of the parties. Theverifier first computes:h=y _(A) +y _(B) +y _(C) +y _(D) mod q

-   -   (that is, the sum of all exponent values; this corresponds to        f+w for the two-party case already described)

The verifier then computes:h′=H ₂(g ^(s) X _(A) ^(y) ^(A) X _(B) ^(y) ^(B) X _(C) ^(y) ^(C) X _(D)^(y) ^(D) mod p ∥ M)

The verifier then checks whether:h′=hholds, and if so, outputs “accept”; otherwise it outputs “rejects”.

With regard to the concurrent-signature algorithm VERIFY, in the presentcase this involves the verifier checking that the components of R_(A),R_(B), R_(C) and R_(D) can all be derived from the keystones K_(A),K_(B) and K_(C) and that each signature satisfies AVERIFY.

Returning to a consideration of the ASIGN process, FIG. 3 shows intabular form the values y_(A), y_(B), y_(C), y_(D) provided by each ofthe parties A, B, C and D. In fact, for each of the parties B, C and D,there exist a number of possible ways of deriving the values y_(A),y_(B), y_(C), y_(D) and FIG. 3 only gives one example. In general terms,the rules for deriving the values of y_(A), y_(B), y_(C), y_(D) can bestated as follows:

-   -   The initial signer A creates respective keystone fix component        values to form the exponent values y_(B), y_(C), y_(D), this set        of values constituting the set R_(A).    -   The intermediate parties B and C each create a single respective        keystone fix component.    -   Each party other than the initial signer derives the set of        exponent values to be used in respect of the other parties by        using its own keystone fix component (if any) and the keystone        fix components or component combinations provided by a preceding        party (all keystone fix components of the preceding parties        should be used). However, the exponent value chosen for a        particular party should not be the same as that already used for        that party by a preceding party. This set of exponent values        constitutes the set R in the signature of the party concerned.    -   Each party computes its own related exponent value (that is, its        value for w) from the exponent values it has determined for the        other parties.

By way of example, the FIG. 3 table could be modified by C choosing:y_(A)=f_(B1)y _(B)=(f _(A1) ⊕f _(A2) ⊕f _(A3))and D choosing:y_(B)=f_(B1)y _(C)=(f _(A1) ⊕f _(A2) ⊕f _(A3))

A further possibility in deriving the exponent values is for at leastone of the intermediate parties to generate more than one keystone fixcomponent. The FIG. 4 table illustrates one possible way of doing thiswhere the second party B generates two keystone fix components which ituses for respective exponent values, a third exponent value then beingderived by the Exclusive OR combination of the keystone fix componentsgenerated by party A. This combination is also used by parties C and Dfor one exponent value, with anther value being based on the ExclusiveOR combination of the two keystone fix components generated by party B.

It may also be noted that the final party D could generate its ownkeystone and from it a keystone fix for use in forming its ambiguoussignature; however, this is generally unnecessary and inefficient sinceparty D would normally then release its keystone with its signature.

The extension of the foregoing 4-party examples to n-parties will beapparent to persons skilled in the art. Thus, the FIG. 4 example can beexpressed for the n party case as follows. Except for the last (n^(th))signer, each signer creates one keystone value and the i^(th) signercomputes a keystone fix with n−i components from his own keystone value;each such component forms one exponent value and further exponent valuesare obtained by using, for each preceding party, the Exclusive Orcombination of the keystone fix components generated by that party. Thei^(th) signer releases his keystone value after received the n ringsignatures and the last n−i−1 keystones. It will be appreciated thatmany variants are possible to the above described embodiments of theinvention. Thus, in the foregoing examples, the public/private key pairs(such X_(A)/x_(A) and X_(B)/x_(B) in the two-party embodiments) can beany type of keys, such as asymmetric keys based on discrete-logarithmproblem (as explained above) or asymmetric keys based on factorizationproblem (e.g. RSA keys). Thus, the corresponding ambiguous signaturescan be discrete-log type signatures or RSA type signatures. Furthermore,the key pairs in a single concurrent signature scheme do not have to besame; thus in a two-party scheme, one key pair can be of thediscrete-log type (with the corresponding signature being, for example,a Schnorr type signature) and the other key pair of the RSA type (withthe corresponding signature being an RSA type signature). The techniquesto be used for achieving concurrent signatures from a variety of keytypes is the same as described for ring signatures in theabove-referenced paper “1-out-of-n signatures from a variety of keys” M.Abe, M. Ohkubo and K. Suzuki; application of these techniques toconcurrent signatures will be apparent to persons skilled in the art.

Whilst each party that generates a keystone fix component has, in theforegoing examples, been described as doing so from a single keystonevalue created by that party, it is also possible for the keystone fixcomponent or components generated by a party to be based on multiplekeystone values created by the party—in other words, the keystonecreated by the party is a set of one or more values (as, in fact,already indicated in the generalized specification of the KGEN algorithmgiven above). Where the keystone comprises multiple values, these areused singly or in combination to form the required number of keystonefix components.

In the foregoing, the ambiguous signature of a party is by conventiontaken to include the the associated set R of keystone fix-relatedvalues. However, it will be appreciated that certain elements of the setR may already be public (for example, in the case of the FIG. 3 example,the element (f_(A1)⊕f_(A2)) which is present in R_(C) is already publicthrough having been included in B's signature). Accordingly, it will notin all cases be necessary for a party to output all components of itsset R so that the release of its signature becomes only a release of theunknown elements of its signature. Nevertheless, the release of onlythese unknown components still has the effect of releasing the signatureas an operative whole.

It should be noted that a keystone can also be used to control when asingle signature is rendered unambiguous—that is, it is not necessaryfor there to be an exchange of signatures. Thus a party A could producean ambiguous signature using an ASIGN algorithm and make this signatureavailable, with the signed data concerned, to other parties, party Athen releasing the keystone at a time of its choosing to commit to itssignature of the data. Of course, in such a situation there is noobvious alternate public key to use (that is, there is no obvious partyto put as the potential alternate signer). Whilst a party could bechosen at random, an alternative approach is for the signing partysimply to obtain a new, unbound, public/private key pair, use the publickey of this key pair in ASIGN, and publish both the public and privatekeys of this new key pair. As a result, anyone could be responsible forgenerating an alternate signature using AltSIGN, this universalambiguity only being removed when the signing party releases thekeystone. Alternatively, a signer can pick a set of public keys each ofwhich belongs to an independent entity, make a ring signature by usingthese public keys and his own private key, and later on release thekeystone to prove the ring signature is actually signed by himself.

Finally, it may be noted that the keystone fix f and the relatedkeystone k can be viewed as together forming a public/private key pair,with the private key k being released to remove ambiguity fromsignatures created using the public key f in the ASIGN signing process.

1. A digital-signature method for use, in signing subject data, by afirst party that has a first public/private key-pair; the methodcomprising the first party generating a keystone and using it, togetherwith at least the private key of the first-party's key-pair, the publickey of at least one other public/private key-pair, and the subject data,to create, in a first way, an ambiguous signature which an independentsignature-checking party, without knowledge of the keystone, can onlyambiguously verify as being one of a set of ambiguous signaturescomprising: an ambiguous signature created in said first way by thefirst party, and a respective ambiguous signature created in a secondway by a possessor of the private key of the or each said otherkey-pair; knowledge of the keystone enabling the signature-checkingparty to determine that the ambiguous signature created by the firstparty was created thereby.
 2. A method according to claim 1, wherein thefirst party uses the keystone to generate, by means of a one-wayfunction, a keystone fix that the first party then uses in the creation,in said first way, of its ambiguous signature on the subject data; thefirst party's ambiguous signature including a set of at least onekeystone-fix-related element and being such that: the said second way ofcreating an ambiguous signature generates an associated alternatekeystone fix rather than using it as an input; and thesignature-checking party requires a said set of at least onekeystone-fix-related element to ambiguously verify a said ambiguoussignature.
 3. A method according to claim 2, further comprising thefirst party making the keystone available to the signature-checkingparty and the signature-checking party carrying out a verificationprocess on a received data set that purports to come from the firstparty and comprises a said ambiguous signature and subject data; theverification process comprising the following operations in any order:(i) a determination of whether the or each element of said set of atleast one keystone-fix-related element included in the ambiguoussignature is derivable from the keystone, and (ii) an ambiguousverification operation for determining, on the basis of the receiveddata set and the public keys of the first and said at least one otherkey-pairs, whether the ambiguous signature in the data set is one of aset of ambiguous signatures comprising: an ambiguous signature createdin said first way by the first party and a respective ambiguoussignature created in said second way by the possessor of the private keyof the or each said other key-pair; positive determinations for bothoperations (i) and (ii) indicating that the signature in the data set isan ambiguous signature created in said first way and was thereforecreated by the first party on the subject data.
 4. A method according toclaim 2, wherein there is only one said other public/private key-pairand the keystone fix constitutes said set of at least onekeystone-fix-related elements.
 5. A method according to claim 4 appliedto an exchange of signatures between the first party and a second partywith which a second public/private key-pair is associated, the methodfurther comprising the second party using the keystone fix generated bythe first party, together with at least the private key of thesecond-party's key-pair, the public key of a further public/privatekey-pair, and second-party subject data, to create, in said first way,an ambiguous signature which the signature-checking party, withoutknowledge of the keystone, can only ambiguously verify as being eitherof: an ambiguous signature created in said first way by the secondparty, and an ambiguous signature created in said second way by apossessor of the private key of said further key-pair; knowledge of thekeystone enabling the signature-checking party to determine that theambiguous signature created by the second party was created thereby. 6.A method according to claim 5, wherein said other key-pair is saidsecond key-pair and prior to release of its ambiguous signature, thesecond party carries out a verification process on a received data setthat purports to come from the first party and to comprise the firstparty's ambiguous signature and subject data; the verification processcomprising the following operations in any order: (i) a determinationthat the second party did not create the received signature set itself,and (ii) an ambiguous verification operation for determining, on thebasis of the received data set and the public keys of the first andsecond key-pairs, whether the ambiguous signature in that data set iseither one of: an ambiguous signature created in said first way by thefirst party and an ambiguous signature created in said second way by thesecond party; the second party only releasing its ambiguous signature ifboth operations (i) and (ii) make positive determinations.
 7. A methodaccording to claim 5, further comprising the first party making thekeystone available to the signature-checking party after receipt of thesecond party's signature whereby to simultaneously render unambiguousthe ambiguous signatures created by the first and second parties.
 8. Amethod according to claim 7, wherein said further key-pair is said firstkey-pair, and wherein prior to releasing the keystone the first partycarries out a verification process on a received data set that purportsto come from the second party and to comprise the second party'sambiguous signature and subject data; the verification processcomprising the following operations in any order: (i) a determinationthat the first party did not create the received signature set itself;and (ii) an ambiguous verification operation for determining, on thebasis of the received data set and the public keys of the second andfirst key-pairs, whether the ambiguous signature in that data set iseither one of: an ambiguous signature created in said first way by thesecond party and an ambiguous signature created in said second way bythe first party; the first party only releasing the keystone if bothoperations (i) and (ii) result in positive determinations.
 9. A methodaccording to claim 7, wherein prior to making the keystone available,the first party carries out a verification process on a received dataset that purports to come from the second party and to comprise thesecond party's ambiguous signature, including a keystone fix, andsubject data; the verification process comprising the followingoperations in any order: (i) a determination of whether the keystone fixof the received data set is the same as that generated by the firstparty from the keystone; (ii) an ambiguous verification operation fordetermining, on the basis of the received data set and the public keysof the second and said further key-pairs, whether the ambiguoussignature in that data set is either of: an ambiguous signature createdin said first way by the second party and an ambiguous signature createdin said second way by the possessor of the private key of the saidfurther key-pair; the first party only releasing the keystone if bothoperations (i) and (ii) result in positive determinations.
 10. A methodaccording to claim 7, further comprising the signature-checking partycarrying out a verification process on first and second received datasets purporting to come from the first and second parties respectivelyand each comprising a said ambiguous signature, including a keystonefix, and subject data; the verification process comprising the followingoperations, in any order: (i) a determination of whether the keystonefixes of the first and second data sets are the same; (ii) adetermination of whether a said keystone fix is derivable from thekeystone; (iii) an ambiguous verification operation for determining, onthe basis of the first data set and the public keys of the first andsaid another key-pairs, whether the ambiguous signature in the firstdata set is either of: an ambiguous signature created in said first wayby the first party and an ambiguous signature created in said second wayby the possessor of the private key of the said other key-pair; (iv) anambiguous verification operation for determining, on the basis of thesecond data set and the public keys of the second and said furtherkey-pairs, whether the ambiguous signature in the second data set iseither one of an ambiguous signature created in said first way by thesecond party and an ambiguous signature created in said second way bythe possessor of the private key of the said further key-pair; positivedeterminations for all operations (i) to (iv) indicating that theexchange of signatures is valid.
 11. A method according to claim 5,wherein said other key-pair is said second key-pair.
 12. A methodaccording to claim 5, wherein said further key-pair is said firstkey-pair.
 13. A method according to claim 5, wherein said other key-pairis said second key-pair and said further key-pair is said firstkey-pair.
 14. A method according to claim 5, wherein said other key-pairis a key-pair made available by the first party to at least one partyother than said first and signature-checking parties.
 15. A methodaccording to claim 5, wherein there are multiple second parties eachwith its own respective second public/private key-pair, there being oneor more said further key-pairs used between the second parties.
 16. Amethod according to claim 15, wherein said other key-pair is a saidsecond key-pair.
 17. A method according to claim 15, wherein the or eachsaid further key-pair is said first key-pair.
 18. A method according toclaim 14, wherein said other key-pair is said second key-pair and the oreach said further key-pair is said first key-pair.
 19. A methodaccording to claim 15, wherein said other key-pair is a key-pair madeavailable by the first party to at least one party other than said firstand signature-checking parties.
 20. A method according to claim 7,wherein said other key-pair is said second key-pair and said furtherkey-pair is said first key-pair.
 21. A method according to claim 10,wherein said other key-pair is said second key-pair and said furtherkey-pair is said first key-pair.
 22. A method according to claim 2,wherein said one-way function is a one-way hash function.
 23. A methodaccording to claim 1, wherein said signature is based on a Schnorrsignature.
 24. A method according to claim 1, wherein said signature isbased on an RSA-type signature.
 25. A method according to claim 5,wherein one signature is based on a Schnorr signature and the other isbased on an RSA-type signature.
 26. A method according to claim 4,wherein: each said key-pair is of the form:X_(i)=g^(x) ^(i) mod p where: X_(i) and x_(i) are the public and privatekeys respectively,x_(i) ε Z_(q), and q are two large primes selected such that q|p−1, andg is an element of (Z/pZ)* of order q; the first party chooses a randomk ε Z_(q) for the keystone and forms a keystone fix f by hashing thekeystone k; the first party uses the keystone fix f together with theprivate key x₁ of the first key-pair, the public key X₂ of the saidother key-pair and the subject data M, to create its ambiguous signatureσ in said first way, as follows: the first party chooses a random valuet ε Z_(q), the first party computes the values:h=H ₂(g ^(t) X ₂ ^(f) ∥ M)w=h−f mod qs=t−w x ₁ mod q said first-type ambiguous signature σ being constitutedby the quantities s, w and f.
 27. A method according to claim 26,further comprising the first party making the keystone k available tothe signature-checking party and the signature-checking party carryingout a verification process on a received data set that purports to comefrom the first party and to comprise said ambiguous signature σ and thesubject data M; the verification process comprising the followingoperations in any order: i) a determination of whether the keystone fixf is derivable from the keystone k, and ii) an ambiguous verificationoperation for determining, on the basis of the received data set and thepublic keys X₁, X₂ of the first and said other key-pairs, whether theambiguous signature in the data set is either of: an ambiguous signaturecreated in said first way by the first party and an ambiguous signaturecreated in said second way by the possessor of the private key x₂ of thesaid other key-pair, this operation being effected as follows: thesignature-checking party computes:h=f+w mod qh′=H ₂(g ^(s) X ₁ ^(w) X ₂ ^(f) ∥ M) the signature-checking party checkswhether the equation:h′=h is satisfied; positive determinations for both operations i) andii) indicating that the signature in the signature set is an ambiguoussignature created in said first way and was therefore created by thefirst party on the subject data.
 28. A method according to claim 4,wherein: each said key-pair is of the form:X_(i)=g^(x) ^(i) mod p where: X_(i) and x_(i) are the public and privatekeys respectively,x_(i) ε Z_(q), p and q are two large primes selected such that q|p−1,and g is an element of (Z/pZ)* of order q; the first party chooses arandom k ε Z_(q) for the keystone and forms components u and v of akeystone fix by hashing the keystone k in combination with first andsecond known quantities respectively; the first party uses thecomponents u and v together with the private key x₁ of the firstkey-pair, the public key X₂ of the said other key-pair and the subjectdata M, to create its ambiguous signature a in said first way, asfollows: the first party chooses a random value t ε Z_(q), the firstparty computes the values:w=g ^(u) X ₂ ^(v) mod ph=H ₂(^(gt) ∥ w ∥ M)s=t−x ₁(h+u) mod q said first-type ambiguous signature a beingconstituted by quantities h and s.
 29. A method according to claim 28,further comprising the first party making the keystone k available tothe signature-checking party and the signature-checking party carryingout a verification process on a received data set that purports to comefrom the first party and to comprise said ambiguous signature σ, thecomponents u and v of the keystone fix, and the subject data M; theverification process comprising the following operations in any order:(i) a determination of whether the components u and v of the keystonefix are derivable from the keystone k, and (ii) an ambiguousverification operation for determining, on the basis of the receiveddata set and the public keys X₁, X₂ of the first and said otherkey-pairs, whether the ambiguous signature in the data set is either of:an ambiguous signature created in said first way by the first party andan ambiguous signature created in said second way by the possessor ofthe private key x₂ of the said other key-pair, this operation beingeffected as follows: the signature-checking party computes:(g ^(t))′=g ^(s) X ₁ ^(h+u) mod qw′=g ^(u) X ₂ ^(v) mod ph′=H ₂((g ^(t))′ ∥ w′ ∥ M) the signature-checking party checks whetherthe equation:h′=h is satisfied; positive determinations for both operations (i) and(ii) indicating that the signature in the signature set is an ambiguoussignature created in said first way and was therefore created by thefirst party on the subject data.
 30. A method according to claim 2,wherein the first party is the first of a series of n parties with thesecond to n^(th) parties each having a respective public/privatekey-pair that together constitute said at least one other key-pair; thei^(th) party in said series: at least where i<n, generating its ownkeystone and from this its own keystone fix, and generating, in its turnalong said series from the first party, an ambiguous signature in saidfirst way using: its own keystone fix, if any, the keystone fixes, orderivatives thereof, of the preceding (i−1) parties, if any, in saidseries, at least the private key of its own key-pair, and the publickeys of the other parties; the said set of at least onekeystone-fix-related element that is included in the ambiguous signatureof the i^(th) party comprising at least one element formed by or fromsaid keystone fixes involved in the generation of the signature, and theambiguous signature of the i^(th) party requiring knowledge of thekeystones of the first i parties in said series to remove its ambiguitywhereby the first party can control, subject to the prior release of thekeystones of the other parties, when all the ambiguous signatures becomeunambiguous concurrently.
 31. A method according to claim 30, furthercomprising the parties releasing any keystone they have created with thefirst party only releasing its keystone after having received thesignature and keystone, if any, of each other party.
 32. A methodaccording to claim 31, further comprising the signature-checking partycarrying out a verification process on received data sets eachpurporting to come from a respective one of said n parties and eachcomprising a said ambiguous signature and subject data; the verificationprocess comprising the following operations, in any order: (i) adetermination of whether the elements of the respective set of at leastone keystone-fix-related element included in the signature of eachreceived data set, are derivable from the keystones; (ii) for eachreceived data set, an ambiguous verification operation for determining,on the basis of that data set and the public keys of the parties,whether the ambiguous signature in the data set is either of: anambiguous signature created in said first way by the party associatedwith the data set and an ambiguous signature created in said second wayby one of the other parties; positive determinations for all operationsof (i) to (ii) indicating that the exchange of signatures is valid. 33.A method according to claim 30, wherein: the keystone fix of the firstparty comprises (n−1) components and the keystone fix of each of atleast the second to (n−1)^(th) parties comprises one component; in thegeneration of the ambiguous signature of the i^(th) party, the publickey of each of the other parties in the series is given a respectiveexponent that is a respective member of a set comprising: the, or one ofthe, keystone fix components, if any, of the i^(th) party, and at leastone keystone fix quantity comprising a component or combination ofcomponents of the keystone fixes of the preceding parties in saidseries, if any, all the keystone fix components of the first to i^(th)parties being incorporated into said exponents used for the signature ofthe i^(th) party and these exponents being included in the signature assaid set of at least one keystone-fix-related element; for each party,the exponents used for its public key in the signatures created by theother parties differ from each other.
 34. A method according to claim30, wherein: the keystone fix of the i^(th) party comprises (n−i)components, in the generation of the ambiguous signature of the i^(th)party, the public key of each of the other parties in the series isgiven a respective exponent that is a respective member of a setcomprising: the or each keystone fix component, if any, of the i^(th)party, and a respective keystone fix quantity formed for each precedingparty in the series by combining the components of its keystone fixusing an exclusive OR function; all the keystone fix components of thefirst to i^(th) parties being incorporated into said exponents used forthe signature of the i^(th) party and these exponents being included inthe signature as said set of at least one keystone-fix-related element;the correspondence of set members to the public keys is moved round foreach increment of i.
 35. A method according to claim 30, wherein saidone-way function is a one-way hash function.
 36. A method according toclaims 30, wherein at least one said signature is based on aSchnorr-type ring signature.
 37. A method according to claim 30, whereinat least one said signature is based on an RSA-type ring signature. 38.A method according to claim 30, wherein at least one keystone comprisesa set of two or more values.
 39. A digital signature method in which afirst party with first and second public/private key-pairs forms anambiguous signature on subject data using at least the private key ofthe first key-pair, the public key of the second key-pair, and thepublic key of a further public/private key-pair the private key of whichis possessed by another party; revelation of the private key of thesecond key-pair being effective to render the signature unambiguous. 40.A concurrent-signature method for simultaneously enabling signatureverification of digitally-signed data exchanged between first and secondparties that have associated respective public/private key-pairs, themethod comprising the steps of: a) the first party: generating akeystone and from this, a keystone fix; generating an ambiguoussignature using the keystone fix, at least the private key of the firstparty's key-pair, the public key of the second party's key-pair, andfirst subject data; making available, at least to the second party, afirst data set comprising the first subject data and the first-party'sambiguous signature including said keystone fix; b) the second party:generating an ambiguous signature using the keystone fix generated bythe first party, at least the private key of the second party'skey-pair, the public key of the first party's key-pair, and secondsubject data; making available, at least to the first party, a seconddata set comprising the second-party's ambiguous signature and thesecond subject data; c) the first party revealing the keystone to removethe ambiguity of the signatures so far as signature-checking parties areconcerned.
 41. A digital signature method wherein each of n parties withrespective public/private key-pairs, creates in turn an ambiguoussignature based on: at least the private key of its own key-pair, thepublic keys of the other parties, at least for the first n−1 signingparties, a keystone fix derived from a keystone created by the partyconcerned, and the keystone fixes of the preceding (i−1) signingparties, if any; the ambiguous signature of the i^(th) party requiringknowledge of the keystones of the first i parties in said series toremove its ambiguity whereby the first signing party can control,subject to the prior release of the keystones of the other parties, whenall the ambiguous signatures become unambiguous concurrently. 42.Apparatus for use, in signing subject data, by a first party that has afirst public/private key-pair; the apparatus comprising: a keystonegeneration arrangement arranged to generate and store a keystone; asigning arrangement arranged to use the keystone or a derivativethereof, together with at least the private key of the first-party'skey-pair, the public key of at least one other public/private key-pair,and the subject data, to create, in a first way, an ambiguous signaturewhich an independent signature-checking party, without knowledge of thekeystone, can only ambiguously verify as being one of a set of ambiguoussignatures comprising: an ambiguous signature created in said first wayby the apparatus, and a respective ambiguous signature created in asecond way by a possessor of the private key of the or each said otherkey-pair; and a keystone release arrangement arranged to release thekeystone whereby to enable the signature-checking party to determinethat the ambiguous signature created by the first party was createdthereby.
 43. Apparatus according to claim 42, wherein the signingarrangement is arranged to generate said signature as a Schnorr-typesignature.
 44. Apparatus according to claim 42, wherein the signingarrangement is arranged to generate said signature as an RSA-typesignature.
 45. Apparatus according to claim 42, wherein the keystonegeneration arrangement is further arranged to generate from saidkeystone, by means of a one-way function, a keystone fix, the signingarrangement being arranged to use the keystone fix in generating saidambiguous signature in said first way, and the signing arrangement beingfurther arranged to provide as part of said ambiguous signature a set ofat least one keystone-fix-related element; said signature being suchthat: the said second way of creating an ambiguous signature generatesan associated alternate keystone fix rather than using it as an input;and the signature-checking party requires a said set of at least onekeystone-fix-related element to ambiguously verify a said ambiguoussignature.
 46. Apparatus according to claim 45, wherein there is onlyone said other public/private key-pair and the keystone fix constitutessaid set of at least one keystone-fix-related elements.
 47. Apparatusaccording to claim 46, further comprising a verification arrangement fordetermining whether an ambiguous signature received from a second partywith which a second public/private key-pair is associated, is anambiguous signature created by the second party using said keystone fixtogether with at least the private key of the second-party's key-pair,the public key of a further public/private key-pair, and second-partysubject data; release of the keystone by the keystone releasearrangement being conditional upon a positive determination by theverification arrangement.
 48. A computer program product which whenexecuting on computing equipment is operative to condition the equipmentto provide the apparatus of claim
 42. 49. Apparatus for use by asignature-checking party to carry out a verification process on areceived data set that purports to come from a first party associatedwith a first public/private key-pair, and to comprise subject data andan ambiguous signature of that data formed in a first way using at leasta keystone fix derived by a one-way function from a keystone of thefirst party, the private key of the first-party's key-pair, and thepublic key of at least one other public/private key-pair, the signatureincluding a set of at least one keystone-fix-related element; theapparatus comprising: an ambiguous-verification arrangement fordetermining on the basis of the received data set, including said set ofat least one keystone-fix-related element, and the public keys of thefirst and said at least one other key-pairs, whether the ambiguoussignature in the data set is one of a set of ambiguous signaturescomprising: an ambiguous signature created in said first way by thefirst party and a respective ambiguous signature created in said secondway by the possessor of the private key of the or each said otherkey-pair, said second way of creating an ambiguous signature being suchthat it generates an associated alternate keystone fix rather than usingit as an input; a keystone-fix-element checking arrangement forreceiving said keystone when released by the first party and fordetermining whether the or each element of said set of at least onekeystone-fix-related element included in the ambiguous signature isderivable from the keystone, and an arrangement responsive to positivedeterminations by both the ambiguous-verification arrangement and thekeystone-fix-element checking arrangement to indicate that the signaturein the data set was created by the first party on the subject data. 50.A computer program product which when executing on computing equipmentis operative to condition the equipment to provide the apparatus ofclaim
 49. 51. Apparatus adapted to carry out the method of claim
 40. 52.A computer program product which when executing on computing equipmentis operative to condition the equipment to provide the apparatus adaptedto carry out the method of claim 40.